mysingingmonstersfandomcom-20200222-history
Talk:Fleechwurm
Infobox/inventory formatting I noticed that the display for this Wublin's inventory was all messed up. I recalled a conversation elsewhere - I believe at the template author's wall - that the use of MultiEggList should be discouraged because nested templates cause the visual editor to malfunction. I have adjusted it to use inline images (unfortunately, thumb|none didn't seem to work), which at least corrects the display. I do wonder, however, if the concern with regard to nested templates breaking the visual editor is still valid, given that this appears to have been referring to the *old* visual editor. The new visual editor doesn't seem to have any problem. DemEyes (talk) 14:43, July 31, 2017 (UTC) : The problem is with the "classic" editor, which still doesn't handle nested templates. Some people still use the "classic" editor; in some respects it's still a lot cleaner and more intuitive than the new "visual" editor. For example, the newer editor's handling of tables is pretty awful. : I still want to modify the Infobox Monster template so it doesn't use nested templates for the Wublin inventory. Something along the lines of giving the it the names of the needed monsters, which would then be used to generate the inventory. : It might be appropriate to come up with a new infobox template for Wublins, since a lot of the regular monster features don't apply to them. BunsenH (talk) 15:28, July 31, 2017 (UTC) :: A new infobox might be more appropriate. As I understand it, the eggs could be handled similar to the Elements in Infobox Monster, e.g. with each egg having its own named parameter for type and count. Alternative methods requiring ParserFunctions exist, but they get messy pretty quickly. I could give a stab at making an appropriate infobox page for review, based on how Infobox Monster is currently being used for the Wublins DemEyes (talk) 18:40, July 31, 2017 (UTC) :::: That's pretty much what I had in mind for the eggs -- multiple parameters. It's a bit tedious to set up, and the code isn't terribly readable just because there are lots of lines with only tiny differences between them. But it does work. :::: I get that kind of thing rather often at work: there's an ugly problem to solve, I come up with a rather ugly solution, everyone (including me) thinks it's ugly but no one can think of a better solution. But I take a firm stand against the attitude of one previous contributor here, which was that it was fundamentally wrong to use a work-around for a system bug, so we MUST live with the consequences of the bug until it's fixed, even though it's somewhat doubtful that that will ever happen. BunsenH (talk) 19:22, July 31, 2017 (UTC) ::::: Yeah, I get that it can be ugly. I'd much prefer the nested templates, myself. However, if that invokes a bug in a tool that many people still use, even when that tool isn't used to edit the content inserted by the template(s) to begin with, I fully understand and agree with the need for working around it, rather than against it. ::::: Ultimately, in practical terms, setting up or adjusting the template code is thankfully just a momentary issue, invoking templates is a lot more user-friendly than the code itself, and for those who feel that even the invocation is too complex, they are primarily used in low maintenance areas and users can ask for assistance (be it hand-holding or just doing the work for them if push comes to shove) at any time :) ::::: I'll see about starting Template:Infobox Wublin DemEyes (talk) 23:01, July 31, 2017 (UTC)